Love it #dupa

🇵🇱 🇵🇱 🇵🇱 This is still a draft for a reason 🇵🇱 🇵🇱 🇵🇱

@FelonEkonom out of curiosity - may I participate in the code review process? 😄

Yes. I will mark this PR as Ready for review, when I fix bugs causing tests to fail

Pipe raw value

Little suggestion, to break this conditional block;

# in the function
atomic_demand = handle_atomic_demand(atomic_demand, atomic_demand_value)
{{:decreased, atomic_demand_value}, atomic_demand}

# in the code abyss...

@spec handle_atomic_demand... 
defp handle_atomic_demand(atomic_demand, atomic_demand_value) do
  if should_overflow?(atomic_demand, atomic_demand_value) do
    overflow_demand(atomic_demand, atomic_demand_value)
  else
    atomic_demand
  end
end

@spec should_overflow?... 
# maybe it would be worth adding doc here?
defp should_overflow?(demand, value) do
   not demand.overflowed? and
    resolved_pull?(demand) and
    resolved_push?(demand) and
    exceeds_capacity?(value, demand.capacity)
end

@spec ..
defp resolved_pull?(demand), do: get_receiver_status(demand) == {:resolved, :pull}
defp resolved_push?(demand), do: get_sender_status(demand) == {:resolved, :push}
defp exceeds_capacity?(value, capacity), do: -1 * value > capacity

🤔

What 0 represent? Could it be dumped into module attr, to avoid magic numbers?

🤔

Little suggestion;

And I guess it would be worth adding documentation to the pop_auto_flow_queues_while_needed function 😬

Pattern match is faster than looping over whole map

Q: Are you sure you want to use {} in the alias? It will be hard for grepping specific context (definitely such as State)

I'd move this part higher, maybe just after the general concept part. Also, for completeness, I'd mention what makes the element corked. It seems it's not taken into account in the pseudocode as well.

yes, because on transition from corcked to uncorcked nothing special happens, until the buffer arrival - then the element processes it immediately, omitting auto_flow_queue

I'd mention it anyway

Since we can have only one popping at a time, we can save some cycles by not getting and putting the queue to the state each time

I can test if it changes anything, but remember, that performance worsening happens even if we don't put anything into auto flow queue.

Maybe popping more than one buffer from each queue at a time would speed it up

Do you mean to do everything in the same way as it is, but just call Enum.random less frequently?

Yes

Is it called pop_queues_and_bump_demand in the real code?

It is quite close, but to be precise, it works like:

def pop_queues_and_bump_demand() do
  if uncorcked do
    onUncorck()
  end
end

So I'd adjust it to reflect the names from the code, it would be easier to follow

here we can potentially store async events in the queue

Do you mean the first case of cond statement? The same condition as there is currently on master, I haven't changed it

On master there's an if, not cond

Yeah, I just transformed if into cond, the logic of the code is the same

No, it's not :P

1st condition in cond is true <=> condition in if is satisfied